[00:00.000 --> 00:04.000]  Welcome, everybody, to my talk, and thank you to Biohacking Village for having me.
[00:04.020 --> 00:07.240]  The title of today is, Why is Healthcare Security Hard?
[00:08.260 --> 00:12.540]  My name is Seth Carmody. I spent eight years at the FDA.
[00:12.540 --> 00:16.360]  I started off as a device reviewer, and then I transitioned
[00:16.360 --> 00:20.180]  to tech policy, and then I recently left the agency and joined
[00:21.180 --> 00:23.100]  a security tech startup.
[00:25.300 --> 00:28.160]  When we start to talk about healthcare economics,
[00:28.160 --> 00:32.120]  we need to first move past the struggles that security
[00:32.120 --> 00:37.140]  folks face, the frustration and the friction, the sticking points,
[00:37.240 --> 00:40.020]  a lack of funding, a lack of traction, and this problem
[00:40.020 --> 00:44.200]  is too big kind of thoughts. And once you
[00:44.200 --> 00:48.360]  are able to move past that, you start to observe some patterns, and what you realize is that
[00:48.360 --> 00:52.080]  these patterns are really just people. It's a collection of people
[00:52.080 --> 00:56.000]  making decisions, and those decisions are based on incentives.
[00:56.000 --> 01:00.040]  And the dude said, you look for the person who benefits. And indeed,
[01:00.040 --> 01:04.600]  once you start to unpack why people in the healthcare space make the decisions they do,
[01:04.600 --> 01:08.020]  especially around security, you start to understand the tension
[01:08.020 --> 01:12.820]  I felt as a regulator, and now still feel as a tech supplier.
[01:13.280 --> 01:16.360]  This talk is really a call to action,
[01:16.360 --> 01:20.040]  and this is the beginnings of shining a light, if only briefly,
[01:20.040 --> 01:23.960]  on the economic forces to provoke questions and really
[01:23.960 --> 01:28.040]  to ultimately prioritize where we spend our career capital. Since our time
[01:28.040 --> 01:32.190]  is precious, we want to spend it on the most impactful endeavors.
[01:37.180 --> 01:39.360]  Professor Ross Anderson wrote a paper
[01:39.360 --> 01:43.440]  from around 2001, what was called
[01:43.440 --> 01:47.680]  Why Information Security is Hard. I didn't know at the time
[01:47.680 --> 01:51.600]  when I was titling my talk for the Biohacking Village, but it's clear now after
[01:51.600 --> 01:55.480]  researching this talk why the titles
[01:55.480 --> 01:59.180]  align. In that paper, which as I understand launched
[01:59.180 --> 02:03.420]  formal research into security economics, Anderson described three market forces that make
[02:03.420 --> 02:07.220]  information security hard. He talks about network effects, such as
[02:07.220 --> 02:12.280]  the race to be first to market, today we launch, tomorrow we fix.
[02:12.360 --> 02:15.720]  He talks about the low marginal costs to produce software
[02:15.720 --> 02:19.540]  and that necessitates that software be sold on its value
[02:19.540 --> 02:23.420]  and not its cost. And lastly, technical lock-in, the software
[02:23.420 --> 02:27.300]  builder, the value of the software builder's company is equal
[02:27.300 --> 02:31.360]  to the total lock-in of all their users. So while I am presumably
[02:31.360 --> 02:35.480]  two decades behind, Professor Anderson states in his reconfigure
[02:35.480 --> 02:39.500]  of security engineering, the prominent textbook that he's authored,
[02:39.500 --> 02:43.560]  that medical devices specifically is an area that needs additional research. And today
[02:43.560 --> 02:47.520]  I intend to show the healthcare version of his key economic insights
[02:47.520 --> 02:50.280]  that make healthcare security hard.
[02:53.200 --> 02:56.320]  Whenever we start to talk about hard problems and things
[02:56.320 --> 03:00.320]  that make it easier, I tend to draw on things that I know well and I know
[03:00.320 --> 03:04.280]  the security space, I know the chemistry space very well, and
[03:04.280 --> 03:08.180]  I start to think of catalysis. And the general concept is that
[03:08.180 --> 03:12.280]  the universe says if you want to travel or go from point A to point
[03:12.280 --> 03:16.520]  B, that's going to cost you, and in catalysis we're talking about energy.
[03:16.580 --> 03:20.240]  But if you add a catalyst, it's like a discount from the universe, like a
[03:20.240 --> 03:24.520]  wormhole, thereby allowing you to reach your destination using fewer resources.
[03:24.920 --> 03:28.260]  And if we consider the significant resource
[03:28.260 --> 03:32.180]  constraints in healthcare security, if we want to be successful,
[03:32.180 --> 03:35.780]  we have to seek out the economic catalysts.
[03:36.100 --> 03:40.460]  So let's pose a thought experiment, and this might be helpful
[03:41.520 --> 03:44.400]  in decomposing a giant problem of healthcare
[03:44.400 --> 03:48.320]  security into some bite-sized chunks. So let's consider the
[03:48.320 --> 03:52.200]  following thought experiment given a specific resource time. The baseline
[03:52.200 --> 03:56.200]  projection on the bottom there basically says
[03:56.780 --> 04:00.380]  to reach some reasonable goal of, say, 90% safety, which is
[04:00.380 --> 04:04.380]  fairly arbitrary, but let's start there. Considering our current trajectory and current
[04:04.380 --> 04:08.620]  progress could take anywhere from 15 to 55 years.
[04:09.320 --> 04:12.220]  And this is the tension I feel. I felt it as a regulator
[04:12.220 --> 04:16.500]  being responsible for the progress of medical device cybersecurity. I felt it as a technology
[04:16.500 --> 04:20.600]  I feel it now even as a technology vendor responsible
[04:20.600 --> 04:24.080]  for making security easier. It's the same problem and the same
[04:24.080 --> 04:29.080]  operating incentives. And I also still feel this sense of urgency.
[04:29.260 --> 04:32.720]  Maybe nothing catastrophic will happen again, but maybe
[04:32.720 --> 04:36.660]  my concern is overblown, but this is the exact point of being
[04:36.660 --> 04:41.400]  prepared for a cyber event. You prepare for the worst and you hope for the best.
[04:41.400 --> 04:44.780]  It would be perfectly acceptable to me to over-prepare,
[04:44.780 --> 04:47.720]  to never need to reap the fruits of preparedness,
[04:47.720 --> 04:52.660]  but whatever your viewpoint is on urgency and preparedness, hopefully we can agree
[04:52.660 --> 04:56.580]  that regression isn't acceptable. And without a hard look and
[04:56.580 --> 05:00.400]  reckoning with the security economics, I fear that the probability that progress languishes
[05:00.400 --> 05:04.900]  or diminishes is too high. So if we can effectively identify the catalysts,
[05:04.900 --> 05:08.620]  we can compress the timeline to a decade or so without any additional
[05:08.620 --> 05:12.580]  effort. And when I envisioned this talk, I really
[05:12.580 --> 05:16.520]  wanted to talk about supply chain and liability together because they're literally
[05:16.520 --> 05:20.840]  the one-two punch of security economics. And when I say liability,
[05:22.080 --> 05:24.000]  I mean that
[05:24.460 --> 05:28.500]  when people produce technology, that there's some culpability to
[05:28.500 --> 05:32.140]  the security debt that's ingrained in that piece of technology.
[05:32.620 --> 05:36.640]  But first, I felt like it was sort of outside the
[05:36.640 --> 05:40.880]  bounds of this talk because we had some real problems in supply chain to solve first,
[05:40.880 --> 05:44.860]  which we'll talk about throughout the talk. The topics
[05:44.860 --> 05:48.860]  of equipment phase-out, legacy equipment, and simulation exercises are important
[05:48.860 --> 05:51.960]  but these topics won't be covered today.
[05:54.120 --> 05:58.420]  I like to frame the concept of healthcare supply chain
[05:58.420 --> 06:02.540]  economics within the supply chain. So that's the first
[06:02.540 --> 06:06.560]  problem that we're going to tackle. And it's a useful
[06:06.560 --> 06:10.340]  framer for all the discussions that will happen.
[06:10.340 --> 06:14.000]  It's kind of low fidelity. Maybe it's only one example. There are plenty
[06:14.000 --> 06:18.400]  of permutations on the supply chain. But here I think we have at least
[06:18.400 --> 06:22.320]  some of the major players represented. There are certainly some simplifications
[06:22.320 --> 06:26.380]  here and parts missing. The general flow is
[06:26.380 --> 06:30.280]  that if we consider that there are a bunch of builders and
[06:30.280 --> 06:34.460]  buyers relationships within the supply chain, we can start to tease apart some of the operating
[06:34.460 --> 06:38.520]  incentives. So tech, from big to small
[06:38.520 --> 06:42.460]  to security to general purpose tech, are supplying medical
[06:42.460 --> 06:46.100]  device manufacturers who act as buyers in this regard
[06:46.100 --> 06:50.220]  who then reassemble these pieces of technology into
[06:51.420 --> 06:54.760]  a medical device or some medical technology.
[06:54.760 --> 06:58.420]  This is specific to medical devices. But they're building it
[06:58.420 --> 07:02.280]  to achieve some intended effect. It could be a pacemaker. It could be
[07:02.280 --> 07:05.840]  an insulin pump. It could be a linear accelerator.
[07:05.840 --> 07:09.820]  And in general, we'll just assume that the medical
[07:09.820 --> 07:13.080]  device manufacturer who's regulated principally by the FDA but there are other
[07:15.380 --> 07:17.800]  regulatory forces that
[07:17.800 --> 07:21.360]  they're selling to principally a healthcare delivery organization or hospital system
[07:21.360 --> 07:25.280]  is a buyer. The hospital then facilitates the
[07:25.740 --> 07:28.960]  interaction of the device with the doctor and then the doctor delivers
[07:29.720 --> 07:33.760]  the therapy of that device to the patient. And all of these stakeholders
[07:33.760 --> 07:37.440]  when the supply chain economics have a role.
[07:38.080 --> 07:41.740]  But the thing is, is that
[07:42.720 --> 07:46.500]  healthcare's core competency is healthcare, not security.
[07:46.500 --> 07:49.780]  And therein lies sort of the first principle
[07:49.780 --> 07:54.260]  of healthcare supply chain economics and represents a
[07:54.260 --> 07:58.000]  significant barrier to overcome. So
[07:58.000 --> 08:01.800]  we typically hear about sort of where the security debt
[08:01.800 --> 08:05.320]  sort of builds up. We hear about what hospitals are doing
[08:05.880 --> 08:10.020]  to secure medical devices and other technologies. And just yesterday, IBM
[08:10.020 --> 08:13.980]  released a report that basically said healthcare is lagging in all
[08:13.980 --> 08:17.900]  key indicators within security. They spend less. They take more
[08:17.900 --> 08:22.120]  time to resolve things. They use less technology to solve a security problem.
[08:22.120 --> 08:25.860]  And this is indicative exactly of the thing that I'm talking about. It's because
[08:25.860 --> 08:30.220]  healthcare's core competency as it should be is healthcare, not security.
[08:30.220 --> 08:34.560]  And this is a core economic principle that specialization
[08:34.560 --> 08:38.600]  is efficient. You wouldn't want hospitals to be security experts
[08:38.600 --> 08:41.900]  because a jack of all trades is a master of none. So
[08:41.900 --> 08:46.320]  if you try to make healthcare security experts,
[08:46.320 --> 08:50.520]  healthcare stakeholders of all varieties, security experts, you get worse
[08:50.520 --> 08:54.500]  healthcare and inadequate security. And furthermore, trying to make everyone
[08:54.500 --> 08:58.580]  security experts is the uncatalyzed path. It will cost the most,
[08:58.580 --> 09:02.340]  will take the longest, and if we take this path, I doubt that we will ever
[09:02.340 --> 09:04.100]  collectively succeed.
[09:06.540 --> 09:10.100]  Make no mistake, secure tech is hard to build.
[09:10.580 --> 09:14.400]  So if we just back one step up from
[09:14.400 --> 09:18.280]  the healthcare delivery organization up into the manufacturer and its supply chain,
[09:18.280 --> 09:22.620]  from the manufacturer perspective, historically there has been a lack of out-of-the-box
[09:22.620 --> 09:26.480]  secure by design solutions. If MDMs, as I like to call them,
[09:26.480 --> 09:30.360]  needed an operating system, a wireless chip, a protocol, MDMs
[09:30.360 --> 09:34.900]  were under similar constraints as HDOs. In order to build life-saving technology,
[09:34.900 --> 09:37.340]  they had to use what was there.
[09:39.360 --> 09:42.460]  And because of the economics that Professor Anderson outlines
[09:42.460 --> 09:46.320]  in his 2000 paper, the components that the MDMs pulled from
[09:46.320 --> 09:50.320]  technology vendors' shelves weren't built with security in mind.
[09:50.460 --> 09:54.220]  Therefore, the security debt was passed to the manufacturer and in turn passed down the chain.
[09:54.220 --> 09:58.020]  And now that security has emerged as top of mind for regulators like the FDA
[09:58.020 --> 10:02.560]  and some leading HDOs, device manufacturers are at an inflection point
[10:02.560 --> 10:06.600]  where they need to buy secure components to build and maintain secure devices.
[10:06.700 --> 10:10.400]  And this transition is hampered by the security economic truth of healthcare.
[10:10.400 --> 10:13.300]  Healthcare's core competency is healthcare as it should be.
[10:13.540 --> 10:18.300]  Don't get me wrong, absolutely, device manufacturers should be building some security engineering
[10:18.300 --> 10:22.780]  capacity. These folks are the guides to the security universe and you need them.
[10:22.780 --> 10:27.680]  To what extent that capacity is built really depends on each individual company.
[10:27.880 --> 10:31.080]  Yet despite the receptivity of device manufacturers to transition
[10:31.080 --> 10:35.600]  and build security capacity, every product security person I've ever met,
[10:35.600 --> 10:38.760]  even the ones that have experienced tremendous success,
[10:38.760 --> 10:42.760]  have struggled in some capacity and scale to get the organization and individual
[10:42.760 --> 10:46.940]  business units to do what's necessary for security for reasons that we'll
[10:46.940 --> 10:51.560]  discuss throughout the talk. Since the transition is arduous,
[10:51.560 --> 10:56.260]  security folks within the device manufacturers need the tech communities help.
[10:56.520 --> 10:58.500]  Device manufacturers need as many out-of-the-box
[10:59.180 --> 11:03.280]  secure-by-design solutions as they can get
[11:03.280 --> 11:07.160]  and make no mistake, secure-by-design, leveraging zero-trust
[11:07.160 --> 11:11.100]  architectures, while not the topic of my talk, is a prerequisite
[11:11.100 --> 11:15.600]  for everything that follows. We can now confront the reality
[11:15.600 --> 11:19.720]  and magnitude of the challenge before us because despite the economic reality,
[11:19.720 --> 11:22.180]  the healthcare supply chain must be secured.
[11:25.440 --> 11:30.000]  We have a saying in chemistry that the best model system is the real thing and you won't know
[11:30.000 --> 11:33.840]  until you try, which means there is no amount of testing that can accurately
[11:33.840 --> 11:38.220]  model real life. I'm not the only one that thinks this way.
[11:38.560 --> 11:41.860]  The story of the DERAC-25 is a classic case study
[11:41.860 --> 11:46.100]  for lawyers, computer scientists, medical physicists, and so on.
[11:46.100 --> 11:49.200]  The case study is exquisitely described by Nancy Levinson's work
[11:49.660 --> 11:52.620]  in a few places. There's an appendix A of her book,
[11:52.620 --> 11:57.640]  Safeware, Systems, Safety, and Computers, and I think there's a separate paper as well.
[11:58.180 --> 12:01.180]  If you're not familiar with the story, a linear
[12:01.180 --> 12:05.780]  accelerator experiences failures over and under, irradiates, and kills some patients.
[12:06.040 --> 12:09.100]  It's a nightmare scenario for every
[12:09.100 --> 12:12.340]  manufacturer, and which they seek to avoid.
[12:12.860 --> 12:16.980]  And the story is probably so cliche and cherry-picked that eyes glaze over every time it's mentioned,
[12:16.980 --> 12:21.200]  but I'd like to use it here to describe two key messages. In particular, there's an FDA
[12:21.200 --> 12:24.940]  quote, which is basically
[12:26.140 --> 12:28.920]  giving feedback to the manufacturer on
[12:28.920 --> 12:32.420]  their corrective action plan, or a plan to fix the issues.
[12:32.720 --> 12:37.140]  The FDA reviewer
[12:37.140 --> 12:40.820]  says the following, we are in the position of saying that the proposed
[12:40.820 --> 12:44.940]  corrective action plan can reasonably be expected to correct the deficiency
[12:44.940 --> 12:49.140]  for which they were developed. We cannot say that we are reasonably confident
[12:49.140 --> 12:53.040]  about the safety of the entire system to prevent or minimize exposure from
[12:53.040 --> 12:56.960]  other fault conditions. And if I can speak for this FDA employee, I
[12:56.960 --> 13:00.800]  think what they're trying to say is what Donald Rumsfeld said so well. There are
[13:00.800 --> 13:04.980]  known knowns and unknown unknowns. They're just properties of the system
[13:04.980 --> 13:08.900]  which we cannot accurately predict. And this gets to the second point,
[13:08.900 --> 13:12.580]  that there's this underlying devotion and subscription, even today, to
[13:12.580 --> 13:16.980]  extrapolating the rate of component failure to the rate of system failure.
[13:17.160 --> 13:20.520]  And when we rely on deterministic values for rates of system
[13:20.520 --> 13:24.700]  failures, history has shown us that those risk models break down. And simply
[13:24.700 --> 13:28.700]  put, the classic probability times severity model is an oversimplified model
[13:28.700 --> 13:31.900]  that trades tractability for fidelity.
[13:32.420 --> 13:36.700]  This exact model breakdown is further exemplified by Richard
[13:36.700 --> 13:40.980]  Feynman and his Roger Commission work. On January 28, 1986,
[13:40.980 --> 13:44.580]  73 seconds after liftoff, the space shuttle Challenger broke apart, killing
[13:44.580 --> 13:49.120]  seven crew members. In the resulting investigation of the Rogers Commission,
[13:49.120 --> 13:52.700]  member and Nobel Laureate Richard Feynman, a theoretical physicist,
[13:52.700 --> 13:56.600]  excoriated NASA management for extrapolating component failure
[13:56.600 --> 14:00.360]  rates to the entire shuttle system. Essentially, managers had
[14:00.360 --> 14:04.520]  concluded that through the use of component failure data,
[14:04.520 --> 14:08.300]  that if the shuttle launched once daily for 300 years, NASA would experience
[14:08.300 --> 14:12.300]  exactly one catastrophic failure, or one failure
[14:12.300 --> 14:16.020]  in 100,000 launches. Feynman's instincts told him otherwise
[14:16.020 --> 14:20.260]  and conversations with engineers resulted in a more realistic figure of
[14:20.260 --> 14:24.360]  one failure in 100 launches. Don't get me wrong, device manufacturers
[14:24.360 --> 14:28.420]  absolutely need to test to reduce risk. However, you will not know
[14:28.420 --> 14:32.320]  the extent until it's marketed. That's a fact. That's why the bar for marketing
[14:32.320 --> 14:36.300]  is not 100% safety and 100% effectiveness. The legal
[14:36.300 --> 14:40.160]  bar is reasonable assurance of safety and effectiveness, and in
[14:40.160 --> 14:44.240]  complex systems, with emergent behavior, you need to collect post-market
[14:44.240 --> 14:47.860]  data, which they do. It's just sub-optimal.
[14:51.480 --> 14:55.440]  Data is important, especially if the data indicate a near miss.
[14:55.460 --> 14:59.280]  Also, as part of the Rogers Commission, Feynman had to explain to NASA what a
[14:59.280 --> 15:03.800]  safety factor was. Some early tests of the booster rocket's O-rings
[15:03.800 --> 15:06.560]  resulted in the O-ring burning a third of the way through.
[15:06.560 --> 15:10.000]  NASA managers recorded this result as demonstrating that the
[15:10.560 --> 15:14.180]  O-rings had a safety factor of three, and Feynman had to explain
[15:14.180 --> 15:18.880]  that the safety factor is, in fact, zero. To paraphrase
[15:18.880 --> 15:22.640]  Feynman's example, if a 1,000-pound truck drove across a bridge
[15:22.640 --> 15:26.400]  designed to bear 3,000 pounds and a crack appeared in a beam
[15:26.400 --> 15:30.520]  even just a third of the way through, the safety factor is now zero. The bridge
[15:30.520 --> 15:34.420]  is defective. There was no safety factor at all, even though the bridge
[15:34.420 --> 15:38.720]  did not actually collapse. The data for the O-ring was there.
[15:43.180 --> 15:46.480]  To further build on this idea of systems
[15:46.480 --> 15:50.260]  and uncertainty in systems, as a regulator
[15:50.260 --> 15:54.340]  I had a front-row seat to quite a few economic externalities for security
[15:54.340 --> 15:58.200]  from routine vulnerability disclosures to global cyber attacks.
[15:58.400 --> 16:02.180]  What has been the impact of these events? We have lots of disclosures with
[16:02.320 --> 16:06.140]  a dash of coordination and a pinch of public. We've got WannaCry and
[16:06.140 --> 16:09.820]  Petya and a handful of large impact vulnerabilities that have us questioning
[16:09.820 --> 16:14.360]  why did I choose this field? As a
[16:14.660 --> 16:18.380]  manufacturer, it would be perfectly rational to
[16:19.340 --> 16:22.300]  the event of a disclosure dropping my stock price
[16:22.300 --> 16:26.460]  but ultimately recovering. You might read it with a sigh of relief.
[16:26.460 --> 16:30.420]  I'm glad that's over. What would be the incentive to change
[16:30.420 --> 16:33.980]  in that case? It would be very easy to play the event off as a black swan or
[16:33.980 --> 16:36.620]  an outlier instead of a larger symptom
[16:37.540 --> 16:41.940]  of an underlying issue or a cause to look under the hood or look into the
[16:41.940 --> 16:45.980]  field and see if there's anything else there. And furthermore, because healthcare's
[16:45.980 --> 16:49.900]  job is healthcare, hospitals still need to buy the technology and those darn
[16:49.900 --> 16:53.980]  patients just won't spontaneously get better. It wouldn't surprise me
[16:53.980 --> 16:57.660]  if there were negligible impacts to device and technology sales as a result of taxes
[16:57.660 --> 17:02.080]  potent as WannaCry. So what should
[17:02.080 --> 17:06.460]  we do when our crashes, our visible events are collectively shrugged off?
[17:07.960 --> 17:09.500]  Especially when folks know that there's
[17:10.040 --> 17:13.040]  nothing really that prevents a WannaCry 2.0.
[17:15.540 --> 17:18.160]  And this is the perfect job of
[17:18.160 --> 17:22.200]  the regulator. If the market fails to deliver the correct incentives, this is a primary example
[17:22.200 --> 17:25.940]  of the role of the regulator. If you look at the history of the FDA and think about why the
[17:25.940 --> 17:30.100]  FDA exists, it's about resolving information asymmetry for the consumer.
[17:30.100 --> 17:34.000]  The average person cannot assess the safety and efficacy of a drug or device
[17:34.000 --> 17:37.960]  and even if they could, it would be economically inefficient, not to mention ridiculous, that if
[17:38.620 --> 17:42.400]  before you ate or started chemo or passed out from a cardiac event,
[17:42.400 --> 17:46.140]  you had to evaluate the safety and efficacy of a product you needed.
[17:46.160 --> 17:49.980]  So you need an impartial body to see what's in the meat or
[17:49.980 --> 17:54.040]  evaluate the claim of a drug or device. And therein lies, again, the security
[17:54.040 --> 17:58.140]  economics of healthcare. Healthcare is healthcare, not security. So you
[17:58.140 --> 18:01.980]  are then reliant, as a consumer and patient,
[18:01.980 --> 18:05.980]  you're reliant on the entire supply chain to deliver healthcare and deliver security.
[18:05.980 --> 18:10.180]  It just doesn't work efficiently. It doesn't scale. It doesn't solve the problem on a timeline
[18:10.180 --> 18:14.040]  that we desire. Nicholas Taleb, the author of
[18:14.040 --> 18:17.900]  The Black Swan, offers us another brilliant explanation for the challenge of
[18:17.900 --> 18:22.280]  healthcare's transition to security. The idea of a Black Swan event or a low-probability
[18:22.280 --> 18:26.460]  event is often disregarded as possible, if regarded at all,
[18:26.460 --> 18:30.380]  and therefore isn't present in our risk models. Now, Taleb was talking about
[18:30.380 --> 18:34.480]  the uncertainty present in financial systems, but the concept applies directly
[18:34.480 --> 18:38.380]  to healthcare as well. We're so concerned with the probabilities, and indeed
[18:38.380 --> 18:42.240]  it is the foundation of risk management, that we've convinced ourselves
[18:42.240 --> 18:47.200]  that a security event is a Black Swan event, not an everyday occurrence.
[18:51.910 --> 18:54.070]  In 1990, the GAO released
[18:54.350 --> 18:57.530]  a report the FDA knew of less than 1%
[18:57.530 --> 19:01.590]  deaths, serious injuries, or equipment failures that occurred in hospitals.
[19:01.590 --> 19:05.410]  And at the time, reporting from hospitals to manufacturers about
[19:05.410 --> 19:09.290]  these events was voluntary, so the law was amended to make it compulsory for user
[19:09.290 --> 19:13.390]  facilities and hospitals to report to device manufacturers and FDA
[19:13.390 --> 19:17.650]  under certain conditions. And the result was a significant uptick in reporting.
[19:19.890 --> 19:21.430]  Separately, in 1999,
[19:21.430 --> 19:25.250]  the Institute of Medicine released a shocking report that the third leading cause of death
[19:25.250 --> 19:28.170]  in the U.S. was about 250,000 deaths.
[19:28.330 --> 19:33.330]  It was absolutely shocking.
[19:35.870 --> 19:37.150]  This study
[19:37.150 --> 19:41.210]  touched off a wave of efforts in hospitals to corral and reduce those
[19:41.210 --> 19:45.270]  errors, and I've seen recent reports into 2020
[19:45.270 --> 19:49.270]  that those deaths due to preventable errors are significantly reduced to around
[19:49.270 --> 19:53.210]  22,000. Regardless of the number, these two pieces of information got me
[19:53.210 --> 19:57.050]  thinking, how many close calls are there? And I wondered, what could be gained by
[19:57.050 --> 20:01.110]  leveraging the technology and connectedness to automatically capture,
[20:01.110 --> 20:05.130]  aggregate, and analyze the data about the performance of the device? In the age
[20:05.130 --> 20:08.950]  of technology, it's absolutely possible and cheap to assess the performance of the device
[20:08.950 --> 20:12.770]  for the betterment of healthcare. I mean, the internet figured out a way to
[20:12.770 --> 20:16.930]  monetize my online behaviors. Why not do something else useful with it?
[20:17.870 --> 20:21.210]  Imagine how difficult it was for the Therac-25 manufacturer
[20:21.830 --> 20:25.070]  AECL to piece together the puzzle as it emerged.
[20:25.070 --> 20:29.150]  We enjoyed the benefits of hindsight, but I imagine in the moment it was quite vexing.
[20:29.150 --> 20:32.510]  You've got people dying, and you can't even reproduce the error, but if
[20:33.180 --> 20:36.630]  you could further leverage the technology
[20:37.120 --> 20:41.370]  already on board to capture the events, black box style,
[20:41.370 --> 20:45.050]  pool and analyze the data, maybe it becomes far easier and far cheaper
[20:45.050 --> 20:49.170]  to respond meaningfully to the real world. We need to
[20:49.170 --> 20:53.790]  pay more attention at the system level. We need to look deeper. We need to collect data.
[20:53.970 --> 20:57.170]  I believe that in the real world, everyday devices experience security
[20:57.170 --> 21:00.330]  events. I mean, events as broadly as possible.
[21:00.710 --> 21:05.310]  People may not be dying, but I'm sure that there are near misses all the time.
[21:05.310 --> 21:09.090]  And if we can show the data, then that creates the incentive to build
[21:09.090 --> 21:13.090]  secure healthcare
[21:13.090 --> 21:17.250]  technology from the ground up. Using secure by design components from the tech
[21:17.250 --> 21:21.250]  industry as well as helps us answer the questions of how
[21:21.250 --> 21:25.230]  much security is adequate. So let's measure it.
[21:25.490 --> 21:29.330]  Heisenberg said it best. He changed the outcome by measuring it. Now he meant it for subatomic
[21:29.330 --> 21:32.090]  particles, but we'll take it here for changing the
[21:33.110 --> 21:35.770]  outcomes of healthcare for the better.
[21:37.190 --> 21:41.390]  And honestly, in order to get across the finish line for security, no security
[21:41.390 --> 21:45.130]  event perceived to be a black swan will get us across the finish line. It will be the
[21:45.130 --> 21:48.990]  innumerable cygnets that are hiding in the weeds of everyday data.
[21:48.990 --> 21:52.270]  And today I learned that cygnets were baby swans.
[21:55.690 --> 21:57.170]  Costanza said that he needed
[21:57.170 --> 22:01.210]  to learn risk management because it was on his resume. Let's not fall
[22:01.210 --> 22:05.030]  into the trap of using oversimplified risk management models because we
[22:05.030 --> 22:09.030]  build our careers on it. The uncertainty of behavior complex system demands
[22:09.030 --> 22:13.070]  the adoption of new, higher fidelity models that are plugged into the real
[22:13.070 --> 22:17.030]  world. For as Feynman put it, mother nature cannot be fooled.
[22:17.110 --> 22:20.150]  And in doing so, we'll begin to reveal the late economic incentives
[22:20.970 --> 22:25.010]  not just for secure by design, but I imagine a host of
[22:25.010 --> 22:28.770]  important clinical items we'll be able to tease out
[22:28.770 --> 22:32.550]  efficiently if failures are related to human factors,
[22:32.950 --> 22:36.950]  humidity, cyber security, bad boards, a software bug, or if it's a Tuesday
[22:36.950 --> 22:40.930]  in April during a full moon, you'll have the data right there. And as we look
[22:40.930 --> 22:44.690]  towards the future of healthcare where outcomes determine who gets paid,
[22:44.690 --> 22:48.950]  it will be the only way. Certainly, tremendous progress has
[22:48.950 --> 22:52.890]  been made, and the groundwork for catalysis and acceleration has been made possible
[22:52.890 --> 22:56.890]  by this progress. You only need to look to the FDA and international regulators
[22:56.890 --> 23:00.130]  recent policies in this space, and quite frankly, the efforts
[23:00.810 --> 23:04.730]  of security champions across the supply chain really to understand how
[23:04.730 --> 23:08.850]  deeply passionate healthcare is about fixing all sorts of problems, including security.
[23:08.850 --> 23:12.750]  We can supercharge their efforts by turning ineffectual black swans into
[23:12.750 --> 23:16.990]  effective everyday economic incentives. Thank you, and I'd be happy to take
[23:16.990 --> 23:17.970]  any questions.
